"since" field for incidents via REST API v2 appears to have undocumented constraints

#1

So! I have a Slack bot that I hooked up to query incidents. I default to since an hour ago. Testing today, I tossed in a large number just to get everything back. Nothing. I tried without the since field. Everything.

That’s odd. Every alert was generated after the since I provided. Did I screw up my code? Checked the docs API tester. Nope, not just me. None of the datetime format examples worked.

On a hunch, looked at an old alert, tried using that date for the since. Ah ha! It worked.

I don’t know what the constraint is, but it appears you have some sort of limitation on what I can put in for since. Perhaps the date of the first alert for our account? Or the date our account was created? Something related to those, or more arbitrary?

Either way, this wasted a little time. It might be worth indicating any constraints on values in the documentation.

Thanks!

1 Like
#2

Hi @pscookiemonster, it sounds like you are referring to the GET incidents endpoint. I did some testing on this just now, and it seems to be working as expected for me. Without seeing the request you sent, it’s difficult to say why you weren’t getting results, but perhaps the date was improperly formatted, or there was a different timezone used. Here is an example of a request URL with both a since and timezone parameter:

https://api.pagerduty.com/incidents?since=2019-03-02T00%3A00%3A00&time_zone=UTC

#3

Ahh! Nope, nothing fancy, here’s the output from your API tester:

REQUEST URL
https://api.pagerduty.com/incidents?since=2019-04-15&time_zone=UTC
"CURL" COMMAND
curl -X GET --header 'Accept: application/vnd.pagerduty+json;version=2' --header 'Authorization: Token token=REDACTED' 'https://api.pagerduty.com/incidents?since=2019-04-15&time_zone=UTC'
REQUEST HEADERS
{
  "Accept": "application/vnd.pagerduty+json;version=2",
  "Authorization": "Token token=REDACTED"
}
RESPONSE BODY
{
  "incidents": [],
  "limit": 25,
  "offset": 0,
  "total": null,
  "more": false
}
RESPONSE CODE
200
RESPONSE HEADERS
{
  "content-type": "application/json",
  "cache-control": "max-age=0, private, must-revalidate"
}

Note that there’s no output!

Now if I flip a single number, this switches to a single onboarding event:

REQUEST URL
https://api.pagerduty.com/incidents?since=2019-04-16&time_zone=UTC
"CURL" COMMAND
curl -X GET --header 'Accept: application/vnd.pagerduty+json;version=2' --header 'Authorization: Token token=REDACTED' 'https://api.pagerduty.com/incidents?since=2019-04-16&time_zone=UTC'
REQUEST HEADERS
{
  "Accept": "application/vnd.pagerduty+json;version=2",
  "Authorization": "Token token=REDACTED"
}
RESPONSE BODY
{
  "incidents": [
    {
      "incident_number": 1,
      "title": "My onboarding incident",
      "description": "My onboarding incident",
      "created_at": "2019-05-15T14:13:17Z",
      "status": "resolved",
      "incident_key": "REDACTED",
      "service": {
        "id": "REDACTED",
        "type": "service_reference",
        "summary": "Default Service",
        "self": "https://api.pagerduty.com/services/REDACTED",
        "html_url": "https://REDACTED.pagerduty.com/services/REDACTED"
      },
      "assignments": [],
      "last_status_change_at": "2019-05-15T14:14:02Z",
      "first_trigger_log_entry": {
        "id": "REDACTED",
        "type": "trigger_log_entry_reference",
        "summary": "Triggered through the website",
        "self": "https://api.pagerduty.com/log_entries/REDACTED",
        "html_url": "https://REDACTED.pagerduty.com/incidents/REDACTED/log_entries/REDACTED"
      },
      "alert_counts": {
        "all": 0,
        "triggered": 0,
        "resolved": 0
      },
      "is_mergeable": true,
      "escalation_policy": {
        "id": "REDACTED",
        "type": "escalation_policy_reference",
        "summary": "Default",
        "self": "https://api.pagerduty.com/escalation_policies/REDACTED",
        "html_url": "https://REDACTED.pagerduty.com/escalation_policies/REDACTED"
      },
      "teams": [],
      "pending_actions": [],
      "acknowledgements": [],
      "basic_alert_grouping": null,
      "alert_grouping": null,
      "last_status_change_by": {
        "id": "REDACTED",
        "type": "user_reference",
        "summary": "REDACTED",
        "self": "https://api.pagerduty.com/users/REDACTED",
        "html_url": "https://REDACTED.pagerduty.com/users/REDACTED"
      },
      "resolve_reason": null,
      "incidents_responders": [],
      "responder_requests": [],
      "subscriber_requests": [],
      "urgency": "high",
      "id": "REDACTED",
      "type": "incident",
      "summary": "[#1] My onboarding incident",
      "self": "https://api.pagerduty.com/incidents/REDACTED",
      "html_url": "https://REDACTED.pagerduty.com/incidents/REDACTED"
    }
  ],
  "limit": 25,
  "offset": 0,
  "total": null,
  "more": false
}
RESPONSE CODE
200
RESPONSE HEADERS
{
  "content-type": "application/json",
  "cache-control": "max-age=0, private, must-revalidate"
}

Finally, if I flip forward even further, I start to get actual incidents, although the behavior is odd. For example, I created a new Service yesterday, and generated some Incidents. When I do since 2019-06-01, these literally don’t return, as if they don’t exist, while if I do since 2019-06-02, they do return. Wat. I thought it might be related to Service created_at date, but if it is, it’s not a direct correlation.

Feel free to poke around our instance. If you need an e-mail to correlate to it, wframe at g dot harvard dot edu.

This isn’t super critical, it’s just bizarre, and down the line could make reporting using the API and our own tooling inconsistent.

Thanks!!

#4

Thanks for that additional information. It turns out that when only the since parameter is specified (and not an until parameter), this endpoint will return incidents for the 30 day period following the date you specify. So in your example, it was looking for incidents from 2019-04-15T00:00:00Z - 2019-05-15T00:00:00Z, which happened to be just before the created_at date of your first incident. To get around this, I would recommend specifying both a since and until parameter.

#5

Ahhh perfect, my apologies, that makes sense!